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XML Signature Requirements 
Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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Abstract 
This document lists the design principles, scope, and requirements 
for the XML Digital Signature specification. It includes requirements 
as they relate to the signature syntax, data model, format, 


cryptographic processing, and external requirements and coordination. 
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1. Introduction 


The XML 1.0 Recommendation [XML] describes the syntax of a class of 
data objects called XML documents. The mission of this working group 
is to develop a XML syntax used for representing signatures on 
digital content and procedures for computing and verifying such 
signatures. Signatures will provide data integrity, authentication, 
and/or non-repudiability. 
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This document lists the design principles, scope, and requirements 
over three things: (1) the scope of work available to the WG, (2) the 
XML signature specification, and (3) applications that implement the 
specification. It includes requirements as they relate to the 
signature syntax, data model, format, cryptographic processing, and 
external requirements and coordination. Those things that are 
required are designated as "must", those things that are optional are 
designated by "may", those things that are optional but recommended 
are designated as "should". 


2. Design Principles and Scope 
1. The specification must describe how to sign digital content, and 


XML content in particular. The XML syntax used to represent a 
signature (over any content) is described as an XML Signature. 


[Charter] 
2. XML Signatures are generated from a hash over the canonical form 
of a signature manifest. (In this document we use the term 


manifest to mean a collection of references to the objects being 

signed. The specifications may use the terms manifest, package or 

other terms differently from this document while still meeting 
this requirement.) The manifest must support references to Web 
resources, the hash of the resource content (or its canonicalized 
form), and (optionally) the resource content type. [Brown, 

List (Solo)] Web resources are defined as any digital content that 

can be addressed using the syntax of XLink locator [XLink]). 

3. The meaning of a signature is simple: The XML Signature syntax 
associates the content of resources listed in a manifest with a 
key via a strong one-way transformation. 

1. The XML Signature syntax must be extensible such that it can 
support arbitrary application/trust semantics and assertion 
capabilities -- that can also be signed. 

[Charter (Requirement1&4), List (Bugbee, Solo) ] 

2. The WG is not chartered to specify trust semantics, but syntax 
and processing rules necessary for communicating signature 
validity (authenticity, integrity and non-repudiation). 
[Charter (Requirement1l)] At the Chairs’ discretion and in order 
to test the extensibility of the syntax, the WG may produce 
non-critical-path proposals defining common semantics (e.g., 
manifest, package, timestamps, endorsement, etc.) relevant to 
signed assertions about Web resources in a schema definition 
[XML, RDF] or link type definition [XLink]. 

Comment: A more formal definition of a signed resource is below. 

The notation is "definition(inputs) :constraints" where definition 

evaluates as true for the given inputs and specified constraints. 


signed-resource (URI-of-resource, content, key, signature): (there 
was some protocol message at a specific time such that "GET(URI- 
of-resource) = content") AND (sign-doc (content, key, sig) ) 
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sign-doc (content, key, signature): signature is the value of a 
strong one-way transformation over content and key that yields 
content integrity/validity and/or key non-repudiability 

4. The specification must not specify methods of confidentiality 
though the Working Group may report on the feasibility of such 
work in a future or rechartered activity. [List (Bugbee) ] 

5. The specification must only require the provision of key 
information essential to checking the validity of the 
cryptographic signature. For instance, identity and key recovery 
information might be of interest to particular applications, but 
they are not within the class of required information defined in 
this specification. [List (Reagle) ] 

6. The specification must define or reference at least one method of 
canonicalizing and hashing the signature syntax (i.e., the 
manifest and signature blocks). [Oslo] The specification must not 
specify methods of canonicalizing resource content [Charter], 
though it may specify security requirements over such methods. 
[Oslo] Such content is normalized by specifying an appropriate 
content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. 
Applications are expected to normalize application specific 
semantics prior to handing data to a XML Signature application or 
specify the necessary transformations for this process within the 
signature. [Charter] 

7. XML Signature applications must be conformant with the 
specifications as follows: 

1. XML-namespaces [XML-namespaces] within its own signature 
syntax. Applications may choose C14N algorithms which do or do 
not process namespaces within XML content. For instance, some 
C14N algorithms may opt to remove all namespace declarations, 
others may rewrite namespace declarations to provide for 
context independent declarations within every element. 

2. XLink [Xlink] within its own signature syntax. For any resource 
identification beyond simple URIs (without fragment IDs) or 
fragmentIDs, applications must use XLink locators to reference 
signed resources. Signature applications must not embed or 
expand XLink references in signed content, though applications 
may choose C14N algorithms which provide this feature. 

3. XML-Pointers [XPointer] within its own signature syntax. If 
applications reference/select parts of XML documents, they must 
use XML-Pointer within an XLink locator. [WS-list (1) ] 

The WG may specify security requirements that constrain the 

operation of these dependencies to ensure consistent and secure 

Signature generation and operation. [Oslo] 
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8. XML Signatures must be developed as part of the broader Web design 
philosophy of decentralization, URIs, Web data, 
modularity/layering/extensibility, and assertions as statements 
about statements. [Berners-Lee, WebData] In this context, existing 
cryptographic provider (and infrastructure) primitives should be 
taken advantage of. [List (Solo) ] 


3. Requirements 
3.1 Signature Data Model and Syntax 


1. XML Signature data structures must be based on the RDF data model 
[RDF] but need not use the RDF serialization syntax. [Charter] 

2. XML Signatures apply to any resource addressable by a locator -- 
including non-XML content. XML Signature referents are identified 
with XML locators (URIs or fragments) within the manifest that 
refer to external or internal resources (i.e., network accessible 
or within the same XML document/package). [Berners-Lee, Brown, 
List (Vincent), WS, XFDL] 

3. XML Signatures must be able to apply to a part or totality of a 
XML document. [Charter, Brown] Comment: A related requirement 
under consideration is requiring the specification to support the 
ability to indicate those portions of a document one signs via 
exclusion of those portions one does not wish to sign. This 
feature allows one to create signatures that have document closure 
[List (Boyer(1)], retain ancestor information, and retain element 
order of non-continuous regions that must be signed. We are 
considering implementing this requirement via (1) a special 
<dsig:exclude> element, (2) an exclude list accompanying the 
resource locator, or (3) the XML-Fragment or XPointer 
specifications -- or a requested change to those specifications if 
the functionality is not available. See List (Boyer(1,2)) for 
further discussion of this issue. 

4. Multiple XML Signatures must be able to exist over the static 
content of a Web resource given varied keys, content 
transformations, and algorithm specifications (signature, hash, 
canonicalization, etc.). [Charter, Brown] 

5. XML Signatures are first class objects themselves and consequently 
must be able to be referenced and signed. [Berners-Lee] 

6. The specification must permit the use of varied digital signature 
and message authentication codes, such as symmetric and asymmetric 
authentication schemes as well as dynamic agreement of keying 
material. [Brown] Resource or algorithm identifier are a first 
class objects, and must be addressable by a URI. [Berners-Lee] 

7. XML Signatures must be able to apply to the original version of an 
included/encoded resource. [WS-list (Brown/Himes) ] 
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3.2 Format 


1. An XML Signature must be an XML element (as defined by production 
39 of the XML1.0 specification. [XML]) 

2. When XML signatures are placed within a document the operation 
must preserve (1) the document’s root element tag as root and (2) 
the root’s descendancy tree except for the addition of signature 
element (s) in places permitted by the document’s content model. 
For example, an XML form, when signed, should still be 
recognizable as a XML form to its application after it has been 
signed. [WS-summary] 

3. XML Signature must provide a mechanism that facilitates the 
production of composite documents -- by addition or deletion -- 
while preserving the signature characteristics (integrity, 
authentication, and non-repudiability) of the consituent parts. 
[Charter, Brown, List (Bugbee) ] 

4. An important use of XML Signatures will be detached Web 
signatures. However, signatures may be embedded within or 
encapsulate XML or encoded content. [Charter] This WG must specify 
a simple method of packaging and encapsulation if no W3C 
Recommendation is available. 


3.3 Cryptography and Processing 


1. The specification must permit arbitrary cryptographic signature 
and message authentication algorithms, symmetric and asymmetric 
authentication schemes, and key agreement methods. [Brown] 

2. The specification must specify at least one mandatory to implement 
signature canonicalization, content canonicalization, hash, and 
signature algorithm. 

3. In the event of redundant attributes within the XML Signature 
syntax and relevant cryptographic blobs, XML Signature 
applications prefer the XML Signature semantics. Comment: Another 
possibility is that an error should be generated, however it isn’t 
where a conflict will be flagged between the various function and 
application layers regardless. 

4. The signature design and specification text must not permit 
implementers to erroneously build weak implementations susceptible 
to common security weaknesses (such as as downgrade or algorithm 
substitution attacks). 


3.4 Coordination 


1. The XML Signature specification should meet the requirements of 
the following applications: 
1. Internet Open Trading Protocol v1.0 [IOTP] 
2. Financial Services Mark Up Language v2.0 [Charter] 
3. At least one forms application [XFA, XFDL] 
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2. To ensure that all requirements within this document are 
adequately addressed, the XML Signature specification must be 
reviewed by a designated member of the following communities: 

1. XML Syntax Working Group: canonicalization dependencies. 

[Charter] 

XML Linking Working Group: signature referents. [Charter] 

XML Schema Working Group: signature schema design. [Charter] 

Metadata Coordination Group: data model design. [Charter] 

W3C Internationalization Interest Group: [AC Review] 

XML Package Working Group: signed content in/over packages. 

XML Fragment Working Group: signing portions of XML content. 

Comment: Members of the WG are very interested in signing and 

processing XML fragments and packaged components. Boyer asserts 

that [XML-fragment] does not "identify non-contiguous portions of 

a document in such a way that the relative positions of the 

connected components is preserved". Packaging is a capability 

critical to XML Signature applications, but it is clearly 
dependent on clear trust/semantic definitions, package application 
requirements, and even cache-like application requirements. It is 
not clear how this work will be addressed. 


YHOU B WD 


4. Security Considerations 


This document lists XML Digital Signature requirements as they relate 
to the signature syntax, data model, format, cryptographic 
processing, and external requirements and coordination. In that 
context much of this document is about security. 
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8. Full Copyright Statement 


Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All 
Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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